Containers vs. Serverless: Thoughts About Your Cloud Strategy

There are many ways to build on AWS. When shaping the strategy for your organization, the following two options should be on your shortlist.

• Containers: Package your source code into containers and leverage AWS’s fully-managed services, providing the compute and storage capacity you need.
• Serverless: Divide the business logic into small functions and deploy them to highly distributed systems providing compute and storage capacity.

But which option fits better? In the following, I provide my criteria to decide on the C-level level.

The modern way to run containers on AWS makes use of the following services:

• Load Balancer (Application Load Balancer) distributes incoming requests among containers.
• Container Cluster (ECS and Fargate) executes containers.
• Relational Database, based on Aurora, a MySQL/PostgreSQL-compatible database optimized for the cloud.

A typical Serverless architecture consists of the following building blocks:

• API Gateway providing a REST interface and forwards the incoming request to Lambda.
• Lambda, a compute runtime for small functions.
• DynamoDB, a document database (NoSQL).

Transformative

How to transform an organization from developing traditional software for on-premises to building cloud-native solutions?

The evolution: level up by using containers instead of virtual machines and a cloud-native relational database instead of an out-of-date database system. Modernize your three-tier architecture by making use of the ALB + Fargate + RDS Aurora stack. The programming paradigms, frameworks, and procedures hardly change. That’s a good option if the majority of developers are very effective with their toolbox and have little desire for change. Still, you benefit from managed services that do a good bit of work for you.

The revolution: turn everything upside down by replacing long-running processes with an event-driven approach, and a SQL database with a NoSQL database. Moving to a cutting-edge technology stack based on API Gateway + Lambda + DynamoDB is a statement. A perfect match to motivate existing developers who love to learn about new technologies. It helps to attract new talent with a cloud mindset as well. Such a change can shake up an organization in both a positive and negative sense.

The investment for starting the revolution and leading it to success will be much higher than the more straightforward way of evolution.

Cloud-Native

AWS offers a wide variety of services. Some services map on-premises technologies 1:1 in the cloud. For example, the Relational Database Service (RDS) offers fully-managed Oracle, Microsoft SQL Server, PostgreSQL, and MySQL databases in the cloud. The underlying technology for a container-based architecture, as described above, is more or less the same as what you are using on-premises.

Other services add a layer of abstraction on top of highly distributed systems. For example, DynamoDB spreads the database between tens or hundreds of machines scaling storage and throughput without the need for provisioning capacity or monitoring resources. A Serverless architecture is based on services with a high level of abstraction and highly distributed systems underneath.

Doing so comes with the following advantages:

• Horizontal scaling allows adapting capacity from zero to (almost) infinity.
• Fault tolerance with the ability to recover from outages automatically without a downtime.
• Fine granular pricing models that do not charge for unused capacity.
• No expenses for operation and maintenance.

But, abstractions and highly distributed systems are complicated. Even when AWS abstracts away a lot of that complexity, your developers have to deal with new challenges like eventual consistency. Also, things like monitoring and debugging are challenging between highly distributed systems.

Rapid

When building a Serverless architecture on AWS, you are putting together building blocks offered by AWS. Think of it as a toolbox that allows you to solve everyday challenges. Your developers contribute the business logic as well as glue code to wire the building blocks.

This approach removes the friction of choosing a programming model, application framework, or open-source module. Therefore, you will hardly find a faster way to implement and deploy a new application.

However, developing and deploying an application with containers can be rapid and straightforward as well. Most important, avoid all the distractions from Kubernetes and OpenShift.

Flexible

But you can’t have everything. The Serverless approach makes many assumptions and comes with some severe limitations. For example, Lambda cannot execute a process that runs longer than 15 minutes. However, in some cases, it is tough to break a problem into such small pieces that it can be processed in 15 minutes. Or, there is almost no alternative to building a single page application (SPA), when going Serverless. Server-side rendering is out of the picture.

An architecture based on containers is much more flexible. Your developers choose the programming models, application frameworks, or open-source modules of their choice. Only a few limitations apply.

Cost-Effective

From a cost perspective, the most crucial difference between Containers and Serverless is the billing model:

• A Container architecture is billed by the resources you provision (CPU, memory, and storage capacity). A minimum of resources is required 24/7 to be able to answer incoming requests.
• All components of a Serverless architecture are billed per request. The system can scale down to zero.

A rule of thumb:

• A Serverless architecture is cost-effective for systems that are used by less than 1,000 users, especially if there are times during the week when the system is not used at all.
• A Container architecture comes with baseline costs. You are paying for idle resources, especially for systems with low to medium load. However, a Container architecture can be more cost-effective in high throughput scenarios with steady workloads.

Probably, infrastructure costs are not your biggest problem. Consider the costs for maintenance and operation as well as know-how development.

Summary

I’d like to summarize this discussion with the following radar chart. Serverless is an excellent choice for building modern applications. But Containers bring a lot to the table as well. The flexibility of a Container architecture should not be underestimated, especially when it comes to solving complex problems.

One more thing, you might not have to decide between Containers and Serverless. Why not adding both options to your cloud strategy? Let developers choose the one that fits best for a specific scenario.